Let’s Unpack the Performance Concerns

From blazing-fast SSR to increasingly complex builds—why some developers are reconsidering Next.js

Next.js at a Crossroads

Once hailed as the golden standard for React-based web apps, Next.js was synonymous with speed, scalability, and SEO.

As of late 2024, it's still widely adopted by giants like Apple, TikTok, and Spotify.

But in 2025, the sentiment is shifting—especially among teams running complex, large-scale applications.

So, what’s going on?

Real Case: Why Some Teams Ditched Next.js

Northflank, a platform for developer tools, recently migrated away from Next.js.

Their marketing and documentation site—once powered by SSR—saw rendering time drop from 700ms to just 20ms after switching to a custom React + Express setup. That’s a 30x improvement.

And they’re not alone in raising concerns.

What's Slowing Down Next.js?

1. App Router + Server Components = Confusion and Latency

Next.js 13 introduced the App Router and React Server Components (RSC).

While promising in theory, the hybrid rendering model (SSR, CSR, ISR, RSC, Streaming) has led to:

• - Unclear hydration order

• - Delayed async component loading

• - Breakages when useEffect doesn’t fire in RSC

• “Convert to client component” warnings, leading to dev frustration

For many, it’s not just a performance issue—it’s a developer experience issue.

2. Turbopack: Fast, But Not Fully Ready

Next.js is transitioning from Webpack to Turbopack, a Rust-based bundler.

But in reality:

• - High CPU spikes on large projects

• - Hot-reloading delays

• - Missing compatibility with some Webpack setups

Early adopters report inconsistent speeds and unpredictable reload behavior. Ironically, some say it’s slower than what it replaced.

3. Static by Default... but Not for Everyone

Next.js leans heavily into static generation(getStatic, ISR). But in 2025, apps are increasingly dynamic and personalized—multilingual support, session-based content, real-time updates.

As a result:

• - Teams are forced into SSR, compromising performance

• - Core Web Vitals like TBT and LCP worsen, especially under load

• - ISR fallbacks lead to complex, hard-to-debug behavior

4. Bundle Bloat: When Optimizations Hurt

Ironically, all the built-in optimizations—image handling, font management, CSS modules—can backfire on complex projects.

• Initial bundles often exceed 1MB

• Hydration is delayed next/image or next/font cause longer load times if misconfigured

5. Edge vs Server: Unclear Boundaries, Real Tradeoffs

Vercel is pushing an Edge-first model, but Edge Functions come with:

• - Cold starts

• - Execution limits

• - Lack of support for native Node modules

On hybrid projects, combining server and Edge behavior makes caching logic unpredictable.

Local dev environments also struggle to accurately emulate the Edge.

6. Misconfiguration Is the Real Culprit

Many slowdowns aren’t Next.js's fault directly. They’re rooted in:

• - Misuse of SSR where SSG works

• - Forgetting “use client” directive → hydration failsNeglecting Suspense wrappers → fallback delays

• - Carrying over Webpack logic into Turbopack

• - Poor caching or router logic

In short, Next.js is fast when used right. But its growing complexity means the margin for error is higher than ever.

What the Devs Are Really Feeling

The phrase “Next.js feels slower” isn’t always about raw numbers. It’s about:

• - Sluggish dev environments

• - Unexpected loading behavior

• - Confusing build outputs

• - Increased debugging time

This isn’t just a technical bottleneck. It’s a UX issue for developers themselves.

So, Is It Really Slower?

Yes—and no.

If you're not careful with configuration, Next.js can feel sluggish. But when properly set up

—with smart use of hybrid rendering, caching, Suspense, and image optimization

—it can still deliver lightning-fast experiences.

The challenge today is not in the framework’s power, but in navigating its growing complexity.

TL;DR – Key Takeaways

• Next.js isn’t inherently slow, but improper use of new features can kill performance

• - App Router + RSC demand a steep learning curve

• - Turbopack is fast but still maturing

• - Dynamic UX often clashes with static-generation-first strategies

• Developers feel the friction more than users—especially during local dev and builds

• Optimization today = deeper understanding, not just toggling config options

Final Word

Next.js remains a top-tier framework—but it’s no longer a plug-and-play solution.

If you're using it in 2025, your success will depend on intentional architecture choices, continuous learning, and, sometimes, knowing when not to use it.

✍️ Dev Performance Note by BUNZEE